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1. 


INTRODUCTION 


The  last  three  tasks  under  this  contract  identified  the 
considerations  and  methodologies  to  be  used  in  the  review  and 
evaluation  of  applications  in  operation  today.  The  purpose 
of  this  application  review  process  is  to  identify  at  what 
point  in  time  it  is  possible,  practical,  and  preferable  to 
migrate  an  application  from  one  level  of  operation  to 
another.  A  parallel  consideration  is  the  issue  of  technology 
insertion  during  the  redesign  and  rewrite  phase  of  the 
migration  effort.  A  determination  must  be  made  as  to  whether 
or  not  the  technology  insertion  is  cost  effective  in  the 
short  run  as  well  as  aligning  the  application  with  the  long 
range  goals  of  the  functional  proponent  and  to  insure  that 
the  goals  of  the  functional  proponent  are  in  concert  with  the 
overall  SYSTEM  GOALS,  fa  £  )  Q. _ 

1.1.  GENERAL 

Proponents,  at  the  functional  level  and  at  other  levels  of 
the  Army  have,  in  the  past,  developed  solutions  for  limited 
scope  problems  which  resulted  in  stand-alone  solutions 
otherwise  known  as  "Stove-Pipe"  systems.  The  "Stove-Pipe" 
systems  have  existed  from  prior  to  the  Republic  of  Vietnam 
(RVN)  conflict  to  today  basically  unchanged  and  they  have 
served  to  satisfy  a  single  commodity  user's  specific  needs 
without  regard  to  the  need  to  share  data  between  themselves 
and  other  systems.  These  systems  were  for  the  most  part 
state-of-the-art  at  the  time  of  conception  or  fielding  and 
were  supportive  of  the  Army  Maneuver  Doctrine  in  effect  when 
they  were  fielded. 

Technological  advancement  in  weapons  systems  and  a  major 
change  in  Maneuver  Doctrine  have  created  a  new  set  of 
performance  requirements  which  are  beyond  the  capability  of 
the  majority  of  the  "Stove-Pipe"  systems. 

Irrespective  of  the  scenario  one  might  chose  to  elect  for  tne 
conduct  of  a  future  conflict,  information,  and  the  ability  to 
analyze  information  in  relation  to  situations  has  become 
increasingly  important.  It  may  well  determine  the  outcome  of 
the  majority  of  future  conflicts.  The  world  has  become 
smaller  and  more  dangerous  as  a  result  of  technological 
advances  in  destructive  power  of  advanced  weapons  systems  and 
the  accuracy  and  speed  of  delivery  of  those  weapons  systems. 

National  defense  is  a  global  proposition  in  support  of  U.S. 
interests  at  home  and  abroad.  The  Army  has  a  significant 
number  of  forces  stationed  throughout  the  world.  Ultimately, 
those  forces  are  where  they  are  to  protect  and  to  shield  the 
U.S.  as  well  as  to  support  our  alliance  partners.  The  costs 
associated  with  the  maintenance  of  this  posture  and  the 


relationship  of  our  trade  position  with  the  rest  of  the  world 
has  also  changed  over  time.  The  costs  have  risen  by  orders 
of  magnitude  and  our  trade  position  is  the  worst  it  has  ever 
been.  These  and  other  factors  are  forcing  the  Army  to  do 
more  and  more  with  less  and  less  resources. 

Computerization,  automation,  and  the  application  of 
electronic  technology  portends  the  major  tools  for 
accomplishing  the  increases  in  productivity,  reliance  and 
flexibility  needed  to  meet  the  changes  dictated  by  our 
position  relative  to  the  rest  of  the  world  and  to  meet  the 
challenge  of  ever  increasing  technological  capacity  world¬ 
wide  . 

The  Army  Information  Systems  must  be  postured  and  optimized 
to  support  three  levels  of  performance  or  three  states. 

o  Peace  Time 

o  Transition  to  War 

o  War 


1.2.  PEACE  TIME 

The  Peace  Time  phase,  also  frequently  referred  to  as  *'go-to- 
work",  can  be  characterized  as  a  maintenance  state  during 
which  we  support  the  level  of  deployment  and  training 
necessary  to  keep  the  force  poised  to  move  through  the 
transition  state  quickly  and  then  smoothly  into  the  war 
state.  This  is  also  a  period  of  continuous  evaluation  and 
reevaluation  of  readiness  and  the  effect  of  our  strategy  and 
plans  to  support  transition  and  go-to-war. 

If  the  force  is  kept  in  a  steady  state  of  preparedness  and 
the  deployed  technology  is  sufficient  to  meet  the  threat 
structure  then  the  amount  of  change  required  in  the 
transition  phase  is  low.  If  the  force  is  permitted  to 
degrade  and  the  Army  is  forced  to  deploy  with  a  capability 
which  is  below  standard  then  we  are  at  risk  and  the  amount  of 
transitional  change  including  the  associated  cost  in  terms  of 
life,  property,  and  territory  go  up.  It  is  important  to  note 
that  there  is  very  little  that  can  be  done  in  the  time 
between  the  Peace-Time  and  War-Time  phase  to  increase  the 
probability  of  a  better  outcome  in  the  early  stages  of 
engagement.  The  preparations  which  require  long  lead  times 
must  be  accomplished  prior  to  the  beginning  of  the  Transition 
phase.  Otherwise,  the  real  danger  is  that  the  outcome  will 
be  determined  before  the  system  is  capable  of  adjusting  to 
new  directions  or  states. 


1.3.  TRANSITION  TO  WAR 


The  Transition  phase  can  be  characterized  as  short  period  of 
time  between  the  Peace-Time  state  and  the  War  state  with  it9 
full  scale  engagements.  During  the  Transition  phase  the 
major  function  is  to  set  in  place  the  resources  necessary  to 
counter  the  threat  where  it  exists  and  to  deploy  other 
resources  to  counter  other  threats  and  to  prepare  to  shift 
from  a  defensive  to  offensive  posture.  Intelligence 
evaluation  is  the  capstone  of  the  transition  phase  as  is 
preplanning  to  move  from  a  relatively  static  state  to  a 
circumstance  where  dynamic  change  in  both  the  defense  and 
private  sector  is  pervasive.  During  the  Peace-Time  phase  one 
might  expect  to  encounter  passive  opposition.  During  the 
Transition  phase  the  passive  actions  will  likely  be 
accompanied  by  active  attempts  to  disrupt,  confuse  and 
destroy  resources,  transport,  C4I. 

The  Transition  phase,  should  we  be  fortunate  enough  to  have 
the  luxury  of  this  interlude  between  Peace  and  War  can  be 
thought  of  as  a  time  in  which  to  prime  our  weapons.  The  same 
is  true  for  the  Information  Systems  Resources.  Traffic  will 
increase  in  the  system  as  a  result  of  heightened  tensions, 
and  the  obvious  need  to  update  incident  reports  as  well  as 
delivery  of  status  reports  on  preplanned  actions.  The  volume 
of  data  which  must  transit  the  system  in  order  to  bring  it  to 
it's  peak  of  preparedness  is  a  function  of  preplanning  and 
prepositioning.  The  less  the  better.  This  is  a  particularly 
good  time  for  the  Electronic  Warfare  (EW)  analyst,  and  one 
must  assume  that  the  oppositions  capacity  to  perform 
sophisticated  EW  analysis  is  excellent.  The  Information 
Systems  Resources  will  be  called  upon  to  deliver  close  to 
peak  efficiency  during  the  transition  phase.  An  additional 
peak  could  be  expected  to  occur  in  the  early  phases  of 
engagement  and  with  the  depletion  of  organic  resources  within 
the  Combat  Support  and  Combat  Service  Support  elements. 

If  we  assume  an  enemy  first  strike,  the  US  forces  will  be  in 
a  defensive  posture  which  dictates  far  more  Information 
System  activity  than  were  we  in  an  offensive  posture.  Far 
more  pressure  is  placed  on  the  commanders  in  a  defensive 
posture.  He  needs  intelligence  upon  which  to  formulate  his 
reaction  to  the  offensive  thrust  and  to  move  from  the  defense 
to  an  offensive  posture.  At  the  same  time,  he  must 
preserve  the  logistical  control  over  the  resources  needed  to 
accomplish  this  goal  dictate  a  real  need  for  current, 
extremely  high  quality  information  as  well  as  decision 
support . 

The  View  of  the  Battle  within  the  dimensions  of  space  and 
time  will  be  critical  at  the  point  of  engagement  as  well  as 
at  the  other  echelons  supporting  the  engagement.  The  thread 
of  C2  is  not  just  Army  but  Joint  and  ranges  from  the  lowest 
element  up  through  the  Theater  and  to  the  NCA.  In  every 


instance,  the  Information  Systems  Resources  will  be  the  main 
and  probably  the  only  means  to  construct  the  View  needed  to 
sustain  the  actions  and  to  coordinate  and  orchestrate  the 
outcome  to  our  maximum  advantage.  Any  breakdown,  as  a  result 
of  incompatibility,  or  loss  of  service  is  a  weak  link  in  the 
chain  of  command  and  ultimately  the  support  elements 
capability  to  provide  the  Combat  Arms  with  the  logistic 
support  to  sustain  the  action. 


1.4.  GO-TO-WAR 

The  Transition  phase  and  the  Go-to-War  phase  should  be  bonded 
throughout  the  whole  system  architecture.  The  Go-to-War 
phase  can  be  described  as  the  application  of  the  resources 
developed  and  set  in  place  in  the  first  two  phases.  The 
winner  is  normally  determined  by  the  ability  and  will  to 
sustain  the  action  longer  than  the  opposition. 


2.  OVERVIEW 


Our  present  day  Information  Systems  are  not  designed  to 
support  sustained  high  volumes  of  quality  information  on  a 
real-time  or  close  to  real  time  basis.  The  systems  have 
developed  and  evolved  over  time  and  reflect  a  processing  and 
communications  capability  which  is  more  in  tune  with  the 
1960’s  rather  than  the  1980's. 


2.1.  SHORTFALLS 

The  vast  majority  of  the  Information  Systems  resources  which 
serve  multiple  users  perform  their  processing  in  a  batch 
mode.  Some  of  the  Information  System  do  have  some  level  of 
on-line  inquiry  and  on-line  services,  but  these  are  in  the 
minority.  The  systems  which  have  on-line,  real-time  or  close 
to  real  time  requirements  need  access  to  data  resident  on 
other  systems  and  within  the  data  bases  of  the  other  systems. 
The  data  is  not  universally  available  nor  is  it  in  a  common 
form . 

ISC/ISEC  are  responsible  for  a  variety  of  systems  classified 
as  STAMIS  or  STAMMIS  depending  upon  your  definition  and  scope 
of  application  of  the  definition  of  a  STAMIS.  The  vast 
majority  of  this  group  of  STAMIS  run  on  or  under  the  ASIMS 
(VIABLE)  Program.  Included  in  this  grouping  are  the  major 
financial,  personnel  and  logistics  systems  for  the  Army. 
STANFINS  and  SIDPERS  are  among  the  largest  of  the  Army’s 
STAMIS  programs.  These  two  programs  more  than  any  others 
interface  and  interact  with  just  about  every  element  in  the 
Army.  Logically,  these  programs  should  be  able  to 


automatically  interact  and  share  data  at  the  data  element 
levels,  as  should  the  logistics  programs  and  the  financial 
systems.  Such  is  not  the  case.  This  same  level  of  interaction 
should  be  true  for  the  systems  of  the  Reserve  Components  and 
the  Active  Component. 

Data  sharing  and  automatic  interface  should  be  a  routine 
system  function  designed  into  the  Hardware/Software/Transport 
suites.  These  systems  have  evolved  from  a  manual,  labor 
intensive  form  of  input/output  (I/O)  ranging  from  mailing  of 
cards  and  tape  to  some  level  of  on-line  transfer  of  batch 
files.  In  recent  years  personal  computers  (PC)  level  devices 
have  been  fielded  to  aid  in  the  I/O  functions.  The 
centralized  processing  sites  have  been  upgraded  to  include 
more  modern  peripheral  sets  (TAPE/DISK)  and  advanced 
processors  with  increased  speed  and  primary  memory 
capacities . 

Concurrent  with  the  increase  in  processing  and  storage 
capabilities,  more  and  more  of  the  labor  intensive  manual 
functions  are  being  automated  or  have  been  at  least  semi- 
automated.  The  processing  capacity  of  the  backbone  systems 
has  never  been  able  to  keep  pace  with  the  demand  for  service. 
Consequently  the  delivery  times  for  the  jobs  in  the  queue 
continue  to  stretch  out  and  the  users  become  more  and  more 
disenchanted  with  the  decreasing  levels  of  performance.  The 
users  optimistically  continue  to  file  new  requirements  for 
services  based  upon  needs  and  the  pressures  of  ever 
increasing  efficiencies.  Those  requirements  are  put  into  the 
service  and  program  queue  and  the  service  agents  satisfy  the 
requirements  within  the  scope  of  their  resources.  Resources 
have  been  traditionally  less  than  requirements  and  some 
services  lag  the  original  identification  of  requirements  by 
as  much  as  a  decade. 

Users  are  becoming  more  and  more  dissatisfied  with  the 
delivery  of  services  from  the  service  agent  and  they 
occasionally  initiate  programs  of  their  own  to  solve  the 
problems  within  their  organic  resources  and  external  to  the 
control  system.  This  has  been  particularly  true  since  the 
introduction  of  low  cost  PC  level  devices. 

This  situation  has  created  a  problem  of  significant 
proportions.  It  has  been  recognized  by  the  Information 
Systems  community,  the  DA  Staff,  the  MACOMs ,  and  the 
proponents  alike  for  at  least  the  last  five  or  six  years.  The 
Information  Systems  response  to  this  urgent  need  for  a 
control  mechanism  to  deal  with  the  exploding  problems  of 
information  was  the  formation  of  a  study  group  from  which 
evolved  the  ISC  and  DISC4 . 

These  problems,  which  still  exist  in  today's  STAMIS 
environment,  are  extensive  and  pervasive.  The  bureaucratic 
inertia  of  the  present  organization  which  must  be  overcome  in 


order  to  implement  even  the  simplest  changes  is  staggering. 
Therefore,  some  of  the  simple  but  effective  changes  which 
normally  could  have  been  implemented  have  not.  DSI  believes 
that  the  tools  used  in  the  present  method  of  management  of 
change  are  inadequate. 


2.2.  GOAL 

The  goal  of  this  paper  then  is  to  identify  the  key  factors 
involved  in  technology  insertion/transf er ,  to  show  the 
relationships  between  these  factors,  and  to  provide 
technology  insertion/transf er  implementation  guidance  that 
will  enhance  the  implementation  of  controlled  change  in  a 
rapid  manner. 

It  is  important  to  be  reminded  of  the  basic  principles 
established  in  Task  #2.  These  principles  are  the  foundation 
upon  which  the  proposed  methodologies  are  based. 

o  Coordination  and  cooperation  at  all  levels  of  the 
Information  Systems  Management  process  is  both 
desirable  and  critical  to  the  successful  advancement 
of  quality  and  quantity  improvements  of  the  services 
provided  to  the  end-user  community . 

o  Reporting  systems  developed  for  the  management  and 
audit  of  the  operations,  planning  and  engineering  of 
the  Information  Mission  Area  (IMA)  resources  should 
employ  the  latest  technology  available  to  the 
managers  and  the  automation  process  should  result  in 
more  productivity  at  the  action  officer  levels.  The 
resultant  productivity  should  be  measurable  and 
sustainable.  The  automation  process  should  resolve 
repetitive  reporting  problem”  at  the  action  officer 
level  as  opposed  to  creating  new  reporting 
requirements . 

o  The  suggested  methodologies  must  be  implemented  by 
the  matrix  personnel  to  the  maximum  extent  feasible, 
and  will  utilize ,  and  institutionalize  to  the  maximum 
extent  possible  and  practical,  information  available 
within  the  public  domain  and  other  Government 
agencies .  Every  attempt  should  be  made  to  capitalize 
on  work  already  done  or  in  progress. 


3.  FACTORS  INVOLVED  IN  TECHNOLOGY  INSERTION 

The  components  of  the  technology  insertion  issue  include  the 
technology  itself,  the  management  structure  used  to  implement 


the  technology  insertion,  the  performance  requirements  of  the 
applications,  and  last  but  not  least  is  cost. 


3.1.  TECHNOLOGY 

The  technology  itself  is  multifaceted  in  its  advertised 
approach  but  it  still  boils  down  to  the  standard  three 
components  of  hardware,  software,  and  transport.  The  three 
previous  tasks  under  this  contract  have  addressed  these 
individual  issues  in  detail  and  in  relation  to  each  other. 
TASK  #2  focused  on  communications  or  transfer  and  how 
ISC/ISEC  could  quickly  improve  the  transfer  acquisition 
process  while  conducting  a  testbed  for  the  "All-Source  Data 
Base"  concept.  TASK  #1  and  TASK  #2  both  presented 
observations  on  hardware  and  its  performance.  In  some  cases 
the  combination  of  the  three  components  resulted  in  component 
and  system  performances  which  are  less  than  optimum.  Task  #1 
analyzed  the  current  predicament  of  software  in  the  STAMIS 
environment.  Task  #3  attempted  to  pull  these  discussions 
together  into  an  overview  and  evaluation  of  the 
considerations  required  prior  to  migration  and  distribution 
of  applications. 


3.1.1.  HARDWARE 

Hardware  development  continues  at  an  explosive  rate. 

Hardware  capacity  far  exceeds  the  capability  of  either 
software  or  transfer  and  will  probably  continue  to  do  so  as 
far  into  the  future  as  we  can  project.  Mainframe  CPU  speed 
is  pushing  the  laws  of  physics  and  chemistry.  Where  an 
absolute  speed  limit  has  apparently  been  reached,  the  use  of 
parallel  processing  and  distributed  processing  are  being 
investigated  as  are  new  components  such  as  gallium-arsenide, 
GaAs .  In  looking  at  the  problem  of  migration  of 
applications,  processing  power  at  the  mainframe  has  not  been 
a  problem.  The  problem  was  that  until  recently  there  was  not 
enough  processing  power  available  at  the  user  level.  The 
once  ubiquitous  dumb  terminal  is  now  being  rapidly  replaced 
with  PCs.  At  the  PC  level  there  are  many  manufacturers  today 
who  produce  inexpensive  hardware  that  is  readily  available  to 
the  government.  Much  of  this  hardware  has  more  than  5  MIPS 
capacity  and  it  is  still  small  enough  to  sit  on  a  desktop. 

Scanner  resolution  and  efficiency  are  improving.  Scanned 
documents  are  now  capable  of  full  page  text  editing  and 
graphics  editing  in  a  variety  of  programs. 

Printers,  dot  matrix  and  laser,  are  better  products  at  a 
lower  cost.  Color  laser  printers  are  finally  reaching  the 
market.  Monochrome  laser  printers  with  resolutions  of  1200 
dpi  by  1000  dpi  are  becoming  available. 


In  the  systems  integration  arena,  multi-vendor  networks  are 
rapidly  improving  their  performance  levels.  At  the  same  time 
the  need  for  systems  integrators  is  growing  rapidly  because 
of  the  complexities  of  set-up  and  a  corresponding  lack  on 
technical  knowledge  in  the  user  community.  Even  with  those 
problems  the  operation  of  the  network  is  being  simplified. 

Other  new  technology  includes  optical  disks.  There  is  both 
good  and  bad  news  concerning  optical  disks.  First  the  good 
news;  capacity  is  continuing  to  increase.  The  bad  news  is 
that  there  is  still  no  standard  operating  system  support  for 
the  optical  disk  and  none  in  sight.  In  the  realm  of  the 
magnetic  media  the  situation  is  much  more  optimistic.  3.5" 
floppy  disk  capacity  is  now  up  to  50  MB  and  5  1/4"  hard  disks 
have  broken  the  1  GIGA  BYTE  barrier.  Magnetic  media  is 
capable  of  200  to  400  percent  more  storage  than  is  currently 
available  when  devices  with  present  technology  are  fielded  in 
the  next  12  to  24  months.  Price  per  MB  of  storage  is 
continuing  to  drop  rapidly.  The  next  high  capacity  hard  disk 
may  be  in  the  2"  to  2.5"  diameter  range  with  the  most  likely 
market  being  in  the  portable  computers.  The  message  is  clear 
that  the  intermediate  future  of  magnetic  media  is  much  better 
than  that  of  optical.  This  kind  capacity  portends  an  end  to 
the  debate  about  which  operating  system  should  the  Army 
require  as  a  standard.  In  fact,  this  kind  of  disk  capacity 
almost  makes  this  debate  a  non-issue.  The  user  has  no 
requirement  or  need  to  know  that  he  may  be  running  Unix  with 
one  application  and  DOS  or  OS/2  or  XYZ  operating  system  with 
another  application.  The  user  simply  inserts  the  desired 
disk  in  the  drive  and  boots  the  system.  Plug  and  play,  to 
use  a  currently  popular  phrase. 


3.1.2.  SOFTWARE 

Numerous  efforts  at  the  micro/mini  computer  level  are 
underway  to  produce  more  object  oriented  programming  and  to 
hide  the  complexities  of  the  system  from  the  user.  The  shift 
is  away  from  forcing  the  user  to  comply  with  the  cryptic  and 
often  "unfriendly"  environments  of  software  today  and  to 
develop  software  that  conforms  to  the  needs  of  the  user.  The 
software  is  being  developed  to  work  the  way  the  user  does  and 
to  present  a  more  logical  or  intuitive  interface  with  the 
user.  The  use  of  graphical  interfaces  will  be  the  dominate 
interface  in  the  near  future.  Other  tools  which  will  aid  in 
the  development  of  better  user  interfaces  are  embedded 
Artificial  Intelligence  (AI)  and  Decision  Support  System 
(DSS)  . 

The  potential  volume  of  I/O  continues  to  be  a  problem,  albeit 
a  decreasing  problem.  The  judicious  use  of  AI ,  DSS,  and 
Executive  Information  Systems  (EIS)  tools  should  go  a  long 
way  toward  eliminating  this  as  an  issue.  Voluminous 
printouts  and  reports  are  the  norm  in  many  places  but  the 
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true  question  is  "Who  really  reads  all  of  information  in 
those  printouts  and  reports?"  or  "If  someone  actually  has  the 
time  to  read  these  volumes  of  information,  then  just  how 
effectively  are  they  applying  their  time  and  talents  to  their 
jobs?". 

EISs  are  beginning  to  replace  DSSs  in  some  commercial 
situations.  There  are  some  leaders  in  private  industry  who 
believe  that  DSS  is  passe.  That  may  be  true  in  industry  but 
the  military  need  for  a  DSS  tool  will  remain  strong  and 
separate  from  EIS.  In  a  combat  situation  or  in  a  critical 
resource  management  situation,  decisions  are  DEMANDED  thus 
the  lasting  requirement  for  DSS  in  the  military.  EIS  is 
similar  to  DSS  in  that  it  extracts  its  data  from  the  same 
types  of  sources,  processes  that  data  into  information,  and 
presents  it  to  the  manager/leader  for  his  use  as  desired.  No 
decisions  are  necessarily  required  in  this  case.  The 
manager/leader  may  simply  use  that  information  to  monitor  the 
pulse  of  his  organization,  to  pinpoint  management  areas  which 
are  out  of  tolerance,  or  to  serve  as  fact  sheets  or  travel 
books  which  can  be  taken  on  trips  to  visit  subordinate  units. 
The  exact  implementation  of  an  EIS  is  only  limited  by  the 
imagination  of  the  developer  and  the  user.  Therefore  EIS  is 
currently  being  sold  as  a  concept,  a  "management  tool"  for 
top  management  first  and  then  it  is  then  being  pushed  down  to 
midlevel  management,  in  some  cases  to  the  equivalent  of  the 
action  officer  level. 

EIS  is  being  sold  as  a  concept  because  it  has  to  be  tailor 
made  for  the  company  and  the  executive (s)  that  are  going  to 
be  using  it.  EIS  intends  to  give  the  executive  or  in  the 
Army's  case,  the  commander,  and  those  who  work  for  him/her 
just  enough  information  at  the  right  time  to  help  them  make 
decisions  or  information  to  monitor  the  efficiency  of  the 
operation  of  their  organization.  There  are  some  advantages 
to  the  use  of  an  EIS.  It  can  be  tailored  to  the 
leadership/management  style  of  the  executives/commanders.  It 
can  also  be  used  for  information  only  purposes  not  requiring 
a  decision.  DSS  tools  used  by  the  military  are  intended  to 
require  that  the  commander  or  staff  officer  make  a  decision 
based  upon  the  data/information  analyzed  by  the  DSS.  While 
some  of  the  techniques  used  by  DSS  and  EIS  are  similar,  the 
intended  purpose  or  goal  of  each  system  is  sufficiently 
different  as  to  prevent  the  free  interchange  of  these  tools. 
Use  of  an  EIS  may  help  reduce  the  reluctance  some  mid  and 
senior  level  managers  have  in  using  a  PC.  The  feeling  that 
the  use  of  a  PC  is  somehow  degrading  to  their  decision  making 
ability  or  that  they  are  simply  for  secretaries  may  be 
lessened  by  the  proper  utilization  of  an  EIS. 

On  the  PC  platform,  the  once  glaring  differences  between  Unix 
and  DOS  are  fading  away  as  an  issue  as  OS/2  begins  to  mature. 
Other  than  the  historical  background  differences  between  Unix 
and  OS/2  the  choice  of  which  operating  system  to  use  or  to 


support  will  soon  be  an  issue  of  major  concern  only  to 
developers  and  not  so  much  so  for  the  users  or  the 
integrators.  Growing  numbers  of  vertical  and  horizontal 
applications  for  each  system  are  being  written  as  well  as 
some  applications  which  will  run  on  either  system.  The 
movement  toward  the  use  of  a  graphical  interface  for  the 
user,  X  Window  System  for  Unix  and  Presentation  Manager  for 
OS/2,  and  the  use  by  both  systems  of  Application  Programs 
Interfaces  (API)  will  effectively  eliminate  many  concerns  the 
user  might  have  about  using  one  or  the  other  of  these 
systems.  The  last  significant  differences  exist  between  the 
Intel  80x86  world  and  the  Motorola  680x0  world  but  even  this 
gap  is  being  closed. 


3.1.3.  TRANSFER 

Communications  speeds  over  voice  circuits  have  reached  at 
least  a  temporary  peak  at  19,200  BPS  and  prices  have  begun  to 
drop.  Communications  over  conditioned  lines  or  special 
dedicated  lines  continues  to  increase  in  speed  and  the  use  of 
added  intelligence.  T3  capabilities  are  now  beginning  to 
show  up  in  larger  businesses.  Communications  with 
mainframes,  especially  in  the  IBM  domain,  is  improving. 

The  bottom  line  is  that  sufficient  compute  power, 
communications  capabilities,  and  intelligent  software  tools 
exist  in  the  DOS,  Mac,  and  Unix  environments  to  support 
application  migration  and  distribution  down  to  most  users 
levels  today. 


3.2.  MANAGEMENT  STRUCTURE 

The  basic  management  structure  needed  to  support  an  effort  of 
this  scale  currently  exists  within  the  ISC/ISEC  community. 
However,  there  should  be  one  agency,  with  the  technical 
wherewithal,  positioned  to  monitor  and  review  the  efforts  of 
the  proponents  and  the  Project  Management  personnel  in  the 
migration  work  on  the  selected  STAMIS.  This  technical  agency 
needs  to  be  in  place  as  the  honest  broker  in  the  selection 
and  proper  use  of  appropriate  technology  for  insertion  into 
the  STAMIS.  Standard  project  management  techniques  apply  in 
this  case  after  the  project  has  been  approved  for  selection 
and  migration  by  this  technical  agency  in  coordination  with 
the  plans  and  operations  elements  in  the  ISC/ISEC 
headquarters. 


3.3.  PERFORMANCE  REQUIREMENTS 


The  selection  of  the  application  must  be  made  using  the 
criteria  proposed  in  Tasks  1,  2,  and  3.  In  this  case,  it  is 


wisest  to  first  pick  those  applications  which  support  Go-to- 
War  missions  as  well  as  those  which  will  produce  the  biggest 
bang  for  the  buck  in  the  redesign.  In  the  latter  category, 
it  is  generally  those  with  the  poorest  performance  followed 
by  those  with  the  most  limited  capabilities. 

After  a  review  of  the  criteria  discussed  in  task  3  the 
following  questions  and  observations  related  to  application 
performance  are  worth  repeating:  "  What  applications  should 
be  selected  for  migration?  What  criteria  should  be  employed 
in  the  selection  process?  Where  will  the  processing  actually 
be  done  after  migration  is  completed?  The  analysis  which  is 
be  conducted  must  include  a  look  at  factors  such  as  priority 
for  migration,  how  migration  will  effect  system  integration, 
what  standards  apply  to  migration  of  the  application  (data 
element,  transfer  protocols,  etc),  what  efforts  toward 
Modernization/Redesign  are  currently  in  place  or  on-going 
which  will  impact  the  migration,  and  what  resource  management 
controls  and  coordination  are  required? 

Unfortunately  for  the  Army  and  the  users  of  the  systems  in 
place  today,  all  existing  applications  need  to  be  improved. 
Not  all  require  extensive  rewriting  or  redesign,  some  can  get 
by  with  minor  modification  or  improvements  in  the  methods 
with  which  they  interface  other  applications.  By  using  the 
priority  scheme  discussed  earlier  which  is  first  look  at  go- 
to-war  then  go-to-work  and  within  these  categories  look  at 
them  from  oldest  to  newest.  The  Go-To-War  applications  would 
then  get  the  first  look.  Incidentally,  it  appears  that  they 
are  also  among  the  oldest  of  the  existing  applications  and 
therefore  stand  to  gain  the  most  from  an  infusion  of 
technology. 

After  the  Go-To-War  applications  were  reviewed  the  Go-To-Work 
applications  would  need  a  similar  analysis.  In  as  much  as 
they  are  the  "work  horses"  of  applications  the  potential 
benefits  from  their  modernization  are  tremendous. 

Productivity  gains  here  can't  be  measured  in  exactly  the  same 
way  they  are  measured  in  industry  but  they  can  be  measured  in 
terms  that  are  important  to  the  Army.  Those  terms  are  (1) 
time  and  (2)  administrative  efficiency.  By  increasing 
administrative  efficiency  you  can  decrease  the  time  needed  to 
perform  this  part  of  the  mission.  That  time,  the  Army's  most 
important  asset  next  to  the  soldier  himself,  can  then  be 
devoted  to  training.  This  lack  of  training  time  because  of 
administrative  burdens  is  the  most  critical  issue  currently 
facing  the  Reserve  Component  (RC)  which  is  more  than  50 
percent  of  our  total  force. 

The  AC  faces  the  same  problem  but  on  more  of  a  daily  basis 
and  from  a  slightly  different  point  of  view.  AC  forces 
simply  have  more  time  available  for  training  than  do  the  RC. 
Most  of  the  routine  administrative  work  in  the  sustaining 
base  is  performed  by  civilian  employees  of  the  Army.  If  the 


civilian  employees  perform  their  work  properly  then  the  AC 
soldiers  will  have  the  resources  (Class  I  thru  X,  real 
estate,  and  information)  to  perform  realistic  training 
missions  or  simulations.  The  reality  of  the  current 
situation  is  that  the  Army  is  continuously  forced  to  ask 
these  employees  to  do  more  and  more  work  with  less  and  less 
resources.  Simply  put,  the  work  load  has  increased  but  the 
budget  has  either  remained  the  same  or  has  decreased. 
Political  factors  are  the  driving  forces  here  and  those 
forces  are  local  as  well  as  national  and  international. 

There  is  no  projected  relief  in  sight.  Therefore  we  must 
work  smarter  and  more  efficiently  with  what  we  have." 

Therefore  it  is  important  that  a  clear  and  concise 
description  must  be  developed  about  the  form  and  function  of 
the  target  application  after  it  has  undergone  redesign  and 
rewrite  to  accommodate  technology  insertion.  A  Migration 
Plan  must  be  developed  which  evaluates  existing  technology 
for  use  in  the  rewrite  or  technology  insertion  effort.  There 
are  a  large  variety  of  technological  tools  available  for 
incorporation  into  applications.  Where  their  use  is 
appropriate  the  tool  should  be  identified  for  possible  use. 
Possible  use  is  emphasized  because  care  must  be  exercised  to 
guarantee  the  selective  use  of  these  tools  and  only 
incorporate  those  where  there  is  an  appropriate  need.  The 
use  of  a  tool  simply  because  it  is  there  is  not  in  the  best 
interest  of  anyone  concerned  and  must  be  discouraged.  For 
example,  there  are  some  applications  which  may  be  best  suited 
to  remain  in  the  batch  mode  of  operation.  The  determination 
about  whether  to  leave  them  in  batch  or  to  what  ever  mode 
they  are  operating  in  must  be  made  early  in  the  development 
of  the  Migration  Plan. 

There  is  another  category  of  products  which  have  tremendous 
potential  in  this  area.  The  category  is  bridges,  software 
bridges.  Successful  bridge  development  extends  product  life 
cycles.  Its  follow-on-processor  design  ensures  that  it 
utilizes  mission-developed  data,  rather  than  bending  mission 
requirements  to  get  data.  A  critical  design  consideration  is 
the  assurance  that  all  applications  offer  interface 
boundaries.  Regardless  of  implementation  language  constraints 
and  application  structure,  software  facilities  like  bridges 
can  utilize  effectively  these  interface  points. 

Still  another  category  is  prototyping.  Prototyping  using 
4GL,  screen  generators  and  DBMS  systems  offers  opportunities 
to  extend  life  cycles  and  to  reduce  costs.  Furthermore,  AR 
25-5  recommends  that  prototypes  be  used  for  problem 
definition,  evaluation,  testing,  and  verification  and 
validation  of  proposed  solutions. 

Prototype  development  can  dramatically  decrease,  if  not 
obviate,  the  time  necessary  to  develop  and  approve 
preliminary  documents  in  the  early  design  stages.  The  most 


compelling  reason  for  prototypes,  however,  is  to  ensure  the 
correctness  and  validity  of  results  gained  by  using  modern 
DBMS  and  4GL  tools  to  discover  bugs  early. 

Use  of  prototyping  to  test  concept  and  the  applications 
performance  is  an  essential  requirement.  Structured 
prototyping  is  the  recommended  option  for  the  majority  of  the 
work  in  this  area  although  rapid  prototyping  certainly  may 
the  a  useful  technique  in  some  cases.  Quality  Assurance  (QA) 
is  also  an  integral  part  software  development,  testing,  and 
acceptance . 

Trade-off  analysis  will  have  to  be  conducted  during  the 
design  phase.  To  prevent  to  use  of  an  application  before  its 
is  ready  requires  that  QA  verifies  design  by  using  software 
metrics . 


4.  RELATIONSHIPS  BETWEEN  THE  FACTORS 


As  was  previously  stated  in  paragraph  3  the  major  factors 
involved  in  technology  insertion/transfer  issues  are 
technology  itself,  management,  application  performance,  and 
cost.  The  relationships  exist  between  the  management,  the 
application  performance,  and  the  cost.  They  are  all  impacted 
by  the  technology. 


4.1.  PROJECT  MANAGEMENT 

Project  Management  is  critical  to  the  success  of  the  more 
complex  of  the  migration  efforts.  One  manager  and  not  many 
will  accelerate  the  migration  and  distribution  effort.  The 
idea  is  to  use  the  minimum  number  of  personnel  but  give  them 
the  most  modern  and  efficient  management  tools  available  to 
do  the  migration  work.  Accordingly  the  Project  Management 
Office  should  also  use  those  same  kind  of  modern  tools  to 
evaluate  the  progress  of  the  redesign/rewrite  effort. 


4.2.  APPLICATION  PERFORMANCE 

The  use  of  software  quality  metrics  may  be  the  only  effective 
way  to  measure  the  performance  of  either  existing  software  or 
software  under  development.  Normally  the  functional 
proponent  has  trouble  articulating  a  reasonable  or  measurable 
performance  standard.  By  helping  to  educate  the  proponent  a 
little  bit  we  may  then  be  able  to  jointly  specify 
performance . 

In  the  course  of  events  as  the  software  design  is  being 
refined  trade-off  analysis  must  be  conducted.  Trade-off 


analysis  is  important  to  insure  that  the  applied  technology 
produces  the  expected  results  and  that  the  performance  can  be 
evaluated  in  terms  of  a  measurable  quality  metric 

One  of  the  major  goals  is  that  the  software  has  to  be 
optimized.  How  is  this  done?  Has  the  software  been 
optimized  to  perform  on  only  one  platform  or  across  multiple 
platforms.  Can  software  really  be  optimized  across  multiple 
platforms  or  only  for  one?  What  considerations  are  involved 
in  this  decision?  Does  processing  occur  as  close  to  the 
source  as  possible?  Are  only  transactions  transferred? 

These  are  the  kinds  of  questions  those  involved  in  the 
technology  insertion  and  migration  process  must  be  asking. 

The  3  tier  architecture  has  to  come  into  question  when 
performance  is  being  discussed.  There  are  occasions  when 
direct  contact  between  the  originator  of  a  request  and  where 
the  data  base  resides.  If  he  has  to  go  through  multiple 
layers  of  common  processing  it  will  probably  defeat 
performance  requirements.  Therefore  we  should  tune  the 
architecture  to  satisfy  the  users  requirements.  The 
requirements  will  suggest  the  kind  of  architecture  but  it  may 
have  and  it  may  be  less  than  3  tiers. 


4.3.  COSTS 

The  decision  to  insert  only  a  little  technology  in  the 
migration  can  speed  up  the  development  effort  thus  saving 
funds  but  at  a  another  cost  of  having  less  capability. 
Conversely,  the  insertion  of  too  much  technology  will  produce 
a  risky  product  which  could  be  difficult  to  maintain  and  to 
debug.  The  balance  is  a  reasonable  amount  of  technology  at  a 
reasonable  cost  (in  funds  and  time)  given  the  environment  in 
which  the  application  will  ultimately  operate.  This  balance 
should  be  addressed  in  the  Migration  Plan  before  the  actual 
work  begins. 


5.  IMPLEMENTATION  GUIDANCE  FOR  TECHNOLOGY  INSERTION 


The  establishment  of  a  responsible  office/agency  to  oversee 
the  actions  involved  with  the  technology  insertion  and 
migration  issue  is  the  most  important  step  in  this  process. 

Project  Management  should  be  constructed  with  a  view  toward 
institutionalizing  the  Cooperation  and  Coordination  scheme. 
People,  particularly  systems  oriented,  technically  skilled 
people  are  in  short  supply.  No  single  agent  within  the 
Information  Systems  Management  structure  has  an  excess  of 
technically  competent  people.  This  alone  should  dictate  the 
necessity  to  share  the  output  of  the  higher  skilled  people  on 


an  Army  wide  basis.  Who  does  it  better  is  really  not 
relevant.  There  are  sufficient  shortfalls  in  all  areas,  so 
much  so  that  the  logic  behind  the  Cooperation  and 
Coordination  scheme  should  be  self  evident,  and  preclude 
diversions  which  have  TURF  as  their  foundation. 

The  selection,  redesign,  fielding,  management,  operation  and 
control  of  the  migrated  systems  which  support  Information 
Management  is  a  shared  responsibility  between  military 
personnel.  Department  of  the  Army  Civilians,  and  the 
supporting  contractors.  NO  one  group  has  the  capability 
without  the  support  and  commitment  of  the  others  to  make  the 
system(s).  The  Best  They  Can  and  Should  Be. 


There  are  many  factors,  particularly  those  dealing  with 
forced  reductions  in  resources,  and  lingering  mutual  distrust 
as  a  result  of  the  handling  of  the  Vietnam  War  which  tend  to 
skew  the  focus  of  one  group  or  the  other  away  from  the 
principal  goal  which  is  national  defense.  National  defense 
is  a  responsibility  of  every  American  regardless  of  their 
position  relative  to  the  actual  performance  of  the  national 
defense  functions.  Collectively  we  must  come  to  grips  with 
the  reality  of  the  potential  negative  impact  of  divided 
focus.  The  lack  of  a  strong  central  focus  causes 
inefficiencies  and  reduces  the  national  capacity  to  preserve 
our  position  as  the  preeminent  bastion  of  freedom. 

The  BOTTOM  LINE  on  the  Status  and  Capability  of  the  Army 
Information  Systems  Resources  are  their  ability  to  support 
the  Go-to-War  functions  and  to  sustain  our  forces  at  a  higher 
level  for  longer  than  an  opponent.  While  it  is  nice  to  have  a 
system  in  place  which  will  provide  the  Commander  with  a 
"close  out  the  end  of  year  budget"  on  time,  you  can't  point 
the  balanced  budget  at  an  enemy  who  is  intent  on  changing  our 
way  of  life  and  expect  a  positive  outcome.  Neither  can  the 
shortfalls  be  resolved  with  study  upon  study  by  every 
conceivable  level  of  the  Army  Hierarchy. 


6.  CONCLUSIONS 


Army  leadership  needs  to  be  convinced  of  the  merits  of  taking 
immediate  action  to  implement  the  redesign  and  rewrite  of 
STAMIS  and  the  concurrent  insertion  of  appropriate  or 
reasonable  technology. 

Funds  needs  to  be  identified  for  this  purpose.  Existing 
funds  need  protection  from  been  diverted  or  siphoned  off 
i.e.»  becoming  "bill  payers"  for  other  projects. 

Standards  are  important  but  need  to  be  of  a  looser  framework 


than  before  while  sights  must  be  aimed  at  specific  target 
levels  of  performance.  Standards  should  guide  direction  and 
not  stifle  innovation.  Traditionally,  we  have  attempted  to 
trade-off  the  opposing  goals  of  modernization  and 
standardization.  By  initially  separating  these  goals,  we 
find  if  we  use  selected  modernization  techniques  such  as 
Software  Bridges  to  solve  the  mission  requirements  then 
standards  do  not  have  to  be  totally  sacrificed  but  may 
instead  be  facilitated.  There  are  some  actions  underway  to 
automate  the  standardization  of  data  elements  process  but  the 
process  still  seems  devoid  of  any  AI  tools  or  techniques. 

The  use  of  AI  would  appear  to  offer  a  speed  up  of  the  effort. 

Big  bang  for  the  buck  pilot  projects  need  to  be  identified 
and  completed  quickly  (in  weeks  and  months,  not  in  months  and 
years).  Effective  action  is  needed  to  increase  the  command's 
credibility  in  the  users  eyes  and  to  strengthen  the  command’s 
position  during  the  PPBES  process. 

All  of  the  tools  are  in  place  to  make  major  strides  forward 
in  the  migration  of  applications,  we  only  need  to  stop 
visiting  the  issue  and  to  take  the  necessary  actions  to 
implement  them. 

The  user's  needs  and  requirements  are  the  sole  reason  for  the 
existence  of  the  ISC  community.  It  is  we  who  must  change  to 
meet  the  users  expectations  and  not  the  users  to  meet  ours. 

If  we  complain  about  the  lack  of  quality  in  the  Information 
Systems  we  operate  for  the  users  it  is  because  others,  just 
like  us,  failed  to  take  the  necessary  action  to  improve  the 
systems  when  they  had  the  chance  to  do  so.  Today,  it  is  our 
chance  to  take  that  action. 


7.  RECOMMENDATIONS 


That  AIRMICS  be  designated  as  the  "Technical  Review  and 
Transfer  Agent"  for  ISC/ISEC.  In  this  role,  AIRMICS  will  be 
the  technical  overseer  of  Technology  Insertion/Transfer  and 
Migration  projects  in  addition  to  their  current  missions. 

That  a  limited  scope  "All-Source  Data  Base"  as  described  in 
Task  #2  be  implemented  as  a  pilot  or  proof  of  process 
project . 

That  ARPMIS  be  selected  as  the  lead  application  for 
Technology  Insertion  and  Migration  testing. 

That  some  level  of  performance  standards  be  implemented  to 
control  development  efforts  during  migration.  As  a 
subordinate  to  performance  standards,  a  level  of  Standard 


Quer.y,  which  may  or  may  not  be  limited  to  ANSI  SQL,  and  a 
level  of  intelligence  be  included  in  all  STAMIS  related  to 
the  needs  of  the  commander  of  deployed  and  deployable 
forces. 

That  functional  proponents  be  actively  involved  with  the 
project  and  if  necessary  that  they  be  taught  how  to  express 
their  functional  performance  requirements  in  terms  that  are 
both  reasonable  and  measurable. 

That  a  Migration  Plan  be  developed/approved  by  AIRMICS  as  a 
first  step  in  the  migration  process  after  ISC/ISEC  commits  to 
the  concept  of  selection  and  rewrite/redesign/migration  of  a 
STAMIS  applications. 

That  Project  Management  be  utilized  to  implement  the 
Migration  Plan  and  that  the  Project  Management  Office  be 
structured  to  support  the  project's  complexity  and  to 
maximize  the  use  of  personnel  dedicated  to  the  project  until 
the  project  is  completed. 
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INTRODUCTION 


This  Addendum  to  TASK  4  is  offered  for  the  purpose  of 
providing  additional  information  and  clarification,  as 
requested,  of  the  TASK  4  WHITE  PAPER  which  was  presented  to 
AIRMICS  on  2  December  1988. 

The  intent  of  this  addendum  is  to  offer  further  details  on  a 
recommended  method  of  implementing  the  solutions  suggested 
and  discussed  in  TASKS  1,  2,  3,  and  4  previously  submitted  by 
DSI .  The  process  herein  described  is  based  upon  three  basis 
categories  or  views:  system  requirements,  necessary 
characteristics,  and  the  actions  necessary  for 
implementation . 


REQUIREMENTS 


The  level  of  performance  needed  to  achieve  the  results  we  are 
seeking  is  not  currently  available  in  the  ISR,  but  if  we 
adopt  the  proper  implementation  methodology,  that  performance 
is  attainable.  The  first  step  in  this  methodology  is  to 
define  the  global  or  system  requirements  which  in  turn  drive 
the  means  we  will  use  to  reach  our  goal.  These  requirements 
define  the  essential  elements  needed  to  create  the  baseline 
environment  through  which  the  higher  performance  levels  are 
reached.  The  requirements  which  concern  us  are  as  follows: 


*  The  requirement  for  interconnection  and  interoperability 
from  the  Echelons  Below  Corps  (EBC)  to  the  highest  tier 
of  the  Information  System  Resource  (ISR) , 

*  the  requirement  for  distributed  processing  and 
distributed  databases, 

*  the  requirement  for  data  sharing, 

*  the  requirement  for  distributed  communications, 

*  the  requirement  for  close  to  "real-time"  performance  for 
go-to-war  functions, 

*  the  requirement  for  continuity  of  operations  (COOP) , 

*  the  requirements  for  system  integrity  and  security, 

*  the  requirement  for  software  portability, 

*  the  requirement  for  simplicity  and  commonality  of 
training  at  all  echelons  of  the  system  (tactical, 


strategic,  and  sustaining  base) , 

*  the  requirement  for  the  system  to  dynamically 
reconfigure  and  reconstitute  itself  when  necessary, 

*  and  the  requirement  for  a  singular  Army  view  of 
information  needs,  processing  methodologies,  and  a 
delivery  scheme. 


CHARACTERISTICS 


Before  the  requirements  listed  above  can  be  addressed  from 
either  an  engineering  or  a  management  point  of  view  there 
must  be  recognition  of  several  basis  characteristics  which 
the  system  must  also  possess.  These  characteristics  are 
actually  precursory  to  the  requirements  and  they  are  as 
follows : 

*  the  ability  to  automate  the  acquisition  and  storage  of 
configuration  data  for  all  installed  information 
systems , 

*  the  ability  to  produce  a  system  diagram  and  its  critical 
control  elements, 

*  the  ability  to  automatically  decompose  the  system  view 
to  its  component  parts, 

*  the  ability  to  capture,  analyze,  and  display  system 
statistics  and  performance  characteristics, 

*  the  ability  to  decompose  the  system  view  down  to  the 
base,  post,  station  or  an  individual  user  and  to  produce 
a  graphic  presentation  of  the  user  and  his  information 
processing  needs  and  capabilities, 

*  the  ability  to  perform  intelligent  analysis  and  produce 
graphic  representation  based  on  addition,  subtraction, 
or  modifications  of  system/subsystem  factors, 

*  and  the  ability  to  articulate  needs  over  time  and  in 
relationship  to  the  threat . scenarios  (to  handle  the 
range  and  mix  of  the  various  situations  which  could 
exist  as  the  nation  moves  from  peace  time  to  transition 
to  war) 


ACTIONS 


The  items  below  are  those  representative  steps  which  need  to 
be  taken  in  order  to  implement  the  solutions  which  have  been 
offered  by  DSI.  The  development  of  these  steps  has  taken 
into  consideration  the  requirements  and  characteristics 
listed  above.  These  steps  do  not  attempt  to  answer  all  of 
the  requirements  and  characteristics  as  shown,  but  they  do 
include  those  which  allow  the  quickest  implementation  and  the 
highest  payoff  for  the  minimum  investment.  The  steps  are 
presented  in  relative  chronological  order.  A  representative 
slice  of  this  solution  could  easily  be  demonstrated  with  a 
proof  of  process  system. 

*  Capture  configuration  data  for  all  systems  including  a 
view  of  as  installed  and  planned  upgrades  for  hardware, 
software,  and  transport. 

*  Provide  a  utility  to  graphically  display  system  and 
subsystems  configuration.  Make  the  utility  available 
down  to  user  level. 

*  Design  a  set  of  common  support  modules  for  use  in  the 
ISC  community  to  include  the  DOIMs,  Engineering,  Plans 
and  Operations.  The  key  is  the  use  of  ONE  common 
reporting  and  status  program. 

*  Provide  a  common  set  of  analysis  and  decision  support 
tools  to  interact  with  IMA  configuration  data  base. 

These  tools  could  and  should  be  used  to  do  capacity 
planning,  capacity  measurement,  modeling  and  simulation. 

*  Integrate  analytical  and  decision  support  tool  set  with 
the  configuration  data  base  and  make  it  available  to  the 
action  officer  level. 

*  Install  total  system  configuration  data  responsibility 
within  ISC.  Configuration  data  is  a  responsibility  of 
ISC.  In  the  fulfillment  of  this  responsibility  the 
ARPMIS  data  base  could  be  populated  with  the  types  of 
additional  data  needed  to  establish  the  ARPMIS 
application  as  the  cornerstone  of  the  basis  environment 
needed  to  achieve  the  improved  performances  being 
sought.  The  coordination  and  cooperation  of  the 
proponent  is  essential  to  the  success  of  this  effort  by 
ISC. 

*  Adopt  a  standard  software  development  methodology. 

*  Prioritize  STAMIS  modernization  and  redesign  scheme, 
with  emphasis  going  to  Go-to-Kar  support  and  the 
interface  between  the  tactical  CSS  ,  the  strategic  and 
the  sustaining  base. 

*  The  development  of  -major  systems  must  be  monitored  to 
insure  that  a  logical  thread  of  commonality  exists 


between  them.  The  development  of  RCAS  in  the  Reserve 
Component  and  the  modernization  and  redesign  of  major 
applications  (STAMIS)  in  the  Active  Component  is  an 
example  of  an  opportunity  which  will  exist  in  the  very 
near  future  to  achieve  this  goal. 


*  Developments  in  other  MACOMs ,  Services,  DoD,  and 

industry  need  to  be  monitored  to  track  potential  overlap 
of  efforts.  Additionally,  technology  developments  need 
to  be  monitored  and  assessed  for  use  or  inclusion  in  the 
systems  as  a  level  of  appropriate  integration.  Thus  a 
summation  of  these  actions  could  be  as  shown  below  if 
one  were  to  do  an  applications  overview 


1  ISMs  I 

I  Interface  I 
I  for  I 

!  Base,  Post, I 
I  and  Station  I 
+ - + 


+ - + 

i  STAMIS  I 


I  Interface  i 
I  for  I 

I  DOIMs,Engrs| 

I  Plns&Opns  ! 
+ - + 


+ - + 

I  TECHNOLOGY  I 
!  DATABASE  I 
I  run  i 

I  by  I 

I  AIRMICS  I 
+ - + 


CONCLUSIONS 


The  development  of  what  might  be  called  an  adjunctive 
knowledge  based  system  could  address  most  of  the  requirements 
and  characteristics  listed  above.  This  system  could 
demonstrate  a  representative  slice  of  the  total  system  which 
must  be  developed  if  we  are  to  increase  the  performance 
levels  in  existence  today. 


